devfandomcom-20200223-history
Talk:CodeLoad
Future features? * Interactive definitions builder + possibility to use/transfer an existing Gadgets set-up * Split the user prefs handling to a separate generic script - would other scripts here find it useful? (Similar scripts: SettingsManager @ Commons / gConfig @ Polish Wikipedia) * Perhaps an actual user preference could be used in the future, as opposed to a protected user page? (introduced w/ MW 1.21, but Wikia seems to be using MW 1.20.1-like version of Options API) - OneTwoThreeFall (talk) 16:43, April 28, 2016 (UTC), upd. 18:06, August 23, 2016 (UTC) Suggestions #Not to bold the title text. #Allow users omitting the titles. #If no options present in a group, the group title is hidden. Also, I think the name "CodeLoad" should be renamed as "Gadgets". KurwaAnticstalk 08:08, August 11, 2016 (UTC) :No.3 is fixed! Re. 1 & 2: what would be the use having no title? That seems odd to me. :Naming this "Gadgets" would be confusing, so it'd be best staying with its current name. - OneTwoThreeFall (talk) 09:40, August 11, 2016 (UTC) ::Maybe "Pseudo-Gadgets"? There are also some gadget options in Wikipedia without titles, and the titles are not bolded. KurwaAnticstalk 10:48, August 12, 2016 (UTC) ::Example: Also in tablet view, the checkboxes don't align well with the labels correctly. :::Can I ask, what's wrong with the current name? In my opinion, anything with "Gadgets" in its name could be confusing, and renaming it now that it's released would be a bit of a hassle. :::Looking at that picture, I suppose the title isn't really required. You can now omit it, and it'll use just the description. :::The checkboxes not aligning with the labels is a Wikia issue. If your browser reports that it supports touch events, Wikia loads an extra stylesheet that heightens a number of elements in a fairly indiscriminate way. You can see the same issue on , for example. - OneTwoThreeFall (talk) 08:49, August 15, 2016 (UTC) Gone The codeload preference page is now gone and shows nothing. KurwaAnticstalk 12:03, August 24, 2016 (UTC) :Now it's back. KurwaAnticstalk 14:18, August 24, 2016 (UTC) ::Sorry about that! I had recently updated the scripts, so the caches were most likely out of synch. - OneTwoThreeFall (talk) 09:57, August 25, 2016 (UTC) More suggestions Normally a script is loaded when the corresponding option is checked, but is it possible to disable a script when the option is checked (loaded when not checked)? KurwaAnticstalk 12:41, September 11, 2016 (UTC) :It's not possible to load a script specifically when an option is not checked. Do you have an example of how this would be useful? - OneTwoThreeFall (talk) 19:37, September 11, 2016 (UTC) A Few Questions I've read the page a couple times and have ran into a few questions trying to implement the script. #Does MediaWiki:CodeLoad-definitions.js and the preferences work in test mode? If it does, I did something wrong and can't figure out what that might be. #In the article definition configuration, is it necessary to use the URL sitename (eg. dev) for local scripts? #Do scripts still need to be imported (in Common.js, Wikia.js, or ImportJS) if they are used in the definitions page? #What exactly is the requiresGlobalPrefs parameter (the description isn't clear to me)? DEmersonJMFM 15:28, December 22, 2016 (UTC) :#It should work, but I've had issues using test mode on newly-created script pages in the past (I suspect it's a Wikia cache issue, but can't always reproduce it). Your definitions page seems to be working fine now that it's been approved. :#Nope, that's not needed. The syntax for the article names is the same as that for the ImportJS page, with the addition that CSS pages are also supported. :#Nope, they don't. For each enabled definition, the CodeLoad script will handle the import of any pages listed in the articles parameter. :#The requiresGlobalPrefs parameter allows people on your wiki to set their own preferences for scripts that weren't written for use with CodeLoad. :Taking the SnowStorm script as an example, a definition like below would let people customize a few parts of the script: "snow": { "title": "Snow", "description": "Creates a gentle winter snowfall", "group": "extras", "articles": [ "Wikia.js/snow.js" ], "preferences": { "enabled": true, "flakesMax": 128, "followMouse": true, "useTwinkleEffect": false } } :For the script to access these preferences, however, it would have to be edited specifically to use CodeLoad (by calling codeLoad.getScriptPrefs("snow")). With the requiresGlobalPrefs parameter, though, CodeLoad will set these variables on the browser's global window object, giving the same effect as including code like either of the below in a normal JS page: window.flakesMax = 128; window.followMouse = true; window.useTwinkleEffect" = false; var flakesMax = 128; var followMouse = true; var useTwinkleEffect" = false; :The script will then use these preferences without needing any changes to support CodeLoad. :Hope this helps, OneTwoThreeFall talk 12:02, December 23, 2016 (UTC) ::Found that, at least for the snow, the script preference is ignored if the script is also imported elsewhere on the wiki (seems like an important note, not sure if that's true for every script though). Thanks for the additional info. DEmersonJMFM 03:36, December 24, 2016 (UTC) ::To be clear, for local scripts I should add codeLoad.getScriptPrefs("snow") (obviously changing "snow") to the top of the script's code, without need for the parameter? And dev scripts should use the parameter? DEmersonJMFM 03:54, December 24, 2016 (UTC) :::That's correct - if the script is also imported elsewhere on the wiki, CodeLoad preferences will have no effect on it. :::It's really up to you. If you're writing a new script specifically for use with CodeLoad, then using codeLoad.getScriptPrefs would be an easy way to use preferences. Otherwise, you can simply set the requiresGlobalPrefs parameter and preferences should work without any changes to the script. - OneTwoThreeFall talk 08:03, December 24, 2016 (UTC) ::::Okay, last questions, hopefully. Removing imports from Common.js, while keeping script configurations on the same page, is fine if the script is in the Codeload definitions (as ImportJS is loaded last)? If a preference is added to the definitions, the configuration isn't needed for that parameter elsewhere either, correct? DEmersonJMFM 14:12, December 24, 2016 (UTC) :::::Yep, that's fine - as you mention, scripts in ImportJS are loaded last, so configuring them in Common.js should work without issue. :::::Yes, if the preference is set via a definition, it isn't needed elsewhere. In fact, CodeLoad will not overwrite any configuration variables if they already have been set (e.g. in Common.js), just in case. - OneTwoThreeFall talk 16:39, December 24, 2016 (UTC) Minor "Script preferences" Page Intro Edit I wanted to suggest the editing of the following sentence: :"Below is a list of special gadgets you can enable for your account." to read :"Below is a list of special gadgets you can enable/disable for your account." instead considering you can do both. DEmersonJMFM 23:13, February 10, 2017 (UTC) :If you can enable something, isn't it generally implied that you can disable it too? For what it's worth, that sentence was copied verbatim from the Gadgets preferences interface. - OneTwoThreeFall talk 09:13, February 12, 2017 (UTC) ::The reason I asked is because most of what I have up for users (at the moment) is just what they can disable, as the majority of the scripts are enabled by default. So, only stating that the scripts/gadgets can be enabled can cause confusion (and from your logic the reverse could be implied too). I would like to think the script, given its name, oughta be more flexible to other possible uses. DEmersonJMFM 00:11, February 13, 2017 (UTC) :::Fair reasons! Perhaps "configure" would be appropriate, considering script settings can be changed too? - OneTwoThreeFall talk 06:17, February 13, 2017 (UTC) ::::Yeah, that seems like an even better choice. DEmersonJMFM 14:52, February 13, 2017 (UTC) ::::: - OneTwoThreeFall talk 19:05, February 13, 2017 (UTC)